1. Field of the Invention
The present invention relates to software tools and services for testing and monitoring the operation of web-based and other server systems.
2. Description of the Related Art
A variety of commercially-available systems exist for allowing companies to monitor the post-deployment performance of their web sites and other server systems. For example, Mercury Interactive Corporation, the assignee of the present application, operates a hosted service that allows customers to monitor their respective web sites as seen by end users in various geographic locations. Web site and server monitoring systems are also available as products that may be installed and operated xe2x80x9cin house.xe2x80x9d Various tools and services also exist for allowing web site operators to load-test and functionality-test their applications and server systems prior to deployment.
One problem with existing monitoring systems is that the web site performance data they collect and report typically fails to reveal the specific application components that are the sources of slow response times seen by end users. Without such information, web site operators and developers may have to resort to tedious experimentation to identify the root causes of application-related performance problems. The present invention addresses this problem.
The present invention provides a monitoring system that monitors the amount of time spent by specific application components, such as Java components, during execution of specific transactions on a web site or other server system. A probe that runs on an application server initially instruments these application components (preferably at component load time) to add code for tracking execution start and stop times. When a monitored transaction is executed by the application server, the probe measures the execution times of the invoked componentsxe2x80x94preferably at the component method level. The resulting measurement data is reported to a reports server, and is preferably used to provide transaction-specific breakdowns of the amount of time spent by each instrumented component, and optionally each instrumented method within such components.
For example, a breakdown report may indicate the amount of time spent by each servlet, Java Server Page, entity EJB (Enterprise JavaBean), and session EJB invoked by a particular transaction, such as a xe2x80x9cloginxe2x80x9d or xe2x80x9cplace orderxe2x80x9d transaction. This data may in turn be used by an operator to determine which components or component types are the sources of application performance problems. The breakdown data may optionally be presented in conjunction with associated transaction response times (as measured, e.g., by client-side agent computers), so that an operator can assess the impact each application component has on response times seen by end users. A report may also be provided that further breaks down the component-level execution times by method, so that developers can identify the specific methods that are the sources of performance problems.
In one embodiment, the probe only monitors transactions initiated by agent-generated transaction request messages that are marked or xe2x80x9ccoloredxe2x80x9d for monitoring. Transactions initiated by actual users are thus ignored, as may be desirable to avoid unduly limiting the performance of the application server. In another embodiment, the probe additionally or alternatively monitors transactions initiated by real users, such as all requests for specific URLs (Uniform Resource Locators).
To instrument Java application components in one embodiment, a patch is initially added to the class loader component of a Java virtual machine installed on the application server. This patch causes the class loader component to pass Java components to an instrumentation component at load time. The Java virtual machine may alternatively be configured, via an associated API (Application Program Interface), to pass the Java components to the instrumentation component. In either case, the instrumentation component preferably determines whether each such application component is to be instrumented for monitoring based on configuration data pre-specified by a user. This configuration data may also specify that only certain methods of a given application component are to be instrumented/monitored. A user of the monitoring system can thereby exclude from monitoring those components and methods that are not believed to be sources of performance problems. The instrumentation component may alternatively be designed to instrument all application components, and/or all method of those components selected for instrumentation.